\chapter{Discussion}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Sub-Table of Content
%  1- Findings
%  2- Limitations
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

We analyze here the results we provided at the end of our
experimentation, and discuss their relevance and applicability within
the scope of our reseach.

We also list \textbf{Lemona}'s limitations and drawbacks in regards to
our objectives.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  Findings
\section{Findings}

\subsection{Applicability}

Our technical proof of concept showed that it is possible to
extensively monitor a system's activity using a solution like
\textbf{Lemona}. We managed to create records of each executed
\emph{system call} within the scope of our limited implementation.

\textbf{Lemona} hooks itself at the entry and exit points of
\emph{system calls} and stores their parameters for future review,
thus allowing us to follow the system's activity step by step.

This means we could develop future versions of \textbf{Lemona}
monitoring a complete set of system calls, and implement forensics
analysis tool capable of reconstructing an attack by querying the
datastore.

\subsection{Performance}

Our experimentation demonstrates that a fully monitored system can
still remain usable and responsive enough for normal use, both for
end-users and production environments in enterprise. However,
intensive monitoring is probably not recommended for high-level
computational servers, which means \textbf{Lemona} might not be an
adequate solution for CPU servers and processing clusters.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  Limitations
\section{Limitations}

\textbf{Lemona}, though designed to be a more complete monitoring
facility than the existing solutions, is of course not
foolproof. These are the various ways that we could think of so far to
circumvent its surveillance, or render it inefficient.

Also, Lemona is not yet complete, and needs some improvements.

\subsection{Break the Pipe or Break the Storage Point}

If the connection between \textbf{Lemona}'s storage point and the
\textbf{Lemona}-enabled monitored host can be severed, then of course
the system will not be able to be recovered from future crashes.

Similarly, an attacker could get control over the storage point, which
mean he or she could not only prevent monitoring of malicious
activities, but also destroy already collected evidence or recovery
data, and erase tracks of its presence.

Possible solutions to this problem reside in the hardening of the
transfer connections and host systems, and maybe also in the use of
multiple storage points and connections. There is however no
completely foolproof solution to this issue, and there will not ever
be one, neither with \textbf{Lemona} or any other system.

\subsection{Stuck the Pipe}

If an attacker can somehow manage to block outgoing connections or to
overflow the network's throughput, then he or she may be able to
perform malevolent activities that will not have the time to be
reported to the storage point before the system is brought to an
unrecoverable crash or before he can tamper with \textbf{Lemona}'s
system.

A solution to this issue would be to force the system to attribute the
highest priority to outgoing packets emitted by the \textbf{Lemona}
reporting components. This is technically possible, but we have not
implemented such a feature so far.

This problem can also occur if \textbf{Lemona} is running on a machine
with a very high traffic load, such as a web-server hosting a
corporate or e-commerce website. The combination of the
\textbf{Lemona}'s auditing throughput and the normal server load might
reach the bandwidth limitation, and \textbf{Lemona}'s reporting could
be delayed, thus allowing an attacker to exploit a vulnerability and
crash the system without it showing in the logs.

A correct adjustement to the load-balancing, taking into consideration
the web-server's network load, theoretically overcomes this problem.

\subsection{Break Lemona}

It is actually possible that an attacker, who would succeed in
performing a privilege escalation, might render \textbf{Lemona}
unusable. If combined with one of the previous method, it means the
system will not be monitored anymore. If it is not, then it means we
will still be able to review the attack procedure used by the
attacker, but we will not be able to examine the data that was
compromised once \textbf{Lemona} was taken down. This could be a
problem if an organization needs to assert its losses and their
criticality.

There is no real solution to avoid this. \textbf{Lemona} is enabled on
a host, and if the host can be compromised, so can be the tracing and
reporting modules.
